home *** CD-ROM | disk | FTP | other *** search
/ Meeting Pearls 1 / Meeting Pearls Vol 1 (1994).iso / installed_progs / util / pgp / pgpamiga / contrib / pgpsendmail / source / todo / text0000.txt < prev    next >
Encoding:
Text File  |  1994-04-16  |  2.9 KB  |  92 lines
  1. ======== BEGIN OF PGP BLOCK ========
  2.   Hi, Peter.
  3.  
  4.  > I just read your code and it looks like joining both versions would be
  5.  > possible but would require pretty much effort. What do you think?
  6.  
  7.   I've been reading your code (it's somewhat bigger!), and it looks
  8. like it might be hard to merge. I guess we have a few options:
  9.  
  10. 1)  Don't do anything (the politician's option :-)
  11.  
  12. 2)  Merge one into the other (hard)
  13.  
  14. 3)  Take ideas from one and add it to the other, making an
  15. Uber-PGPsendmail package :-) and dump the other in  /dev/null
  16.  
  17. 4)  Take ideas from each other. You target Amigas, I target Unices,
  18. have separate source code for each, but distribute it together so that
  19. people don't get confused about "competing" packages (the ultimate
  20. aim, I think).
  21.  
  22.   (3) or (4) look to be the real choice. What do you think?
  23.  
  24.  >  > Great. One thing I'd like to throw out is ideas for header keywords.
  25.  > 
  26.  > That is indeed a good idea. Where do you place this keyword? I would
  27.  > use it as follows:
  28.  > 
  29.  >      To: address
  30.  >      Subject: secret: some subject
  31.  > 
  32.  >      mailbody
  33.  
  34.   Hm. I saw it more as:
  35.  
  36. To: address(es)
  37. Subject: hi there
  38. secure: always return-receipt
  39. [message body]
  40.  
  41. OR:
  42.  
  43. To: address(es)
  44. Subject: Hi there
  45. secure
  46. return-receipt
  47. [message body]
  48.  
  49.   Or some such.
  50.  
  51.  > Then PGPSendmail would scan the subject-line, recognize all keywords
  52.  > and insert "some subject" instead. One could even combine keywords,
  53.  > such as
  54.  > 
  55.  >      Subject: secret+cookie
  56.  > 
  57.  > for example. "cookie" should replace the subject line with a random
  58.  > cookie from a database. :-) What do you think?
  59.  
  60.   Hm. I had planned to move the subject down into the encrpyted
  61. section too, but I figured on a plain "Encrpyted Message" subject line.
  62.  
  63.  >  > I (quickly) incorporated the "secure" keyword. I've thought of an
  64.  >  > "insecure" keyword, as well as "return-receipt" or "discard-receipt"
  65.  >  > keywords. The default action for my PGPsendmail is "return-receipt".
  66.  > 
  67.  > What do these keywords mean exactly? "return-receipt" is obvious, but
  68.  > what do the others do?
  69.  
  70.   "insecure" is don't encrypt, don't even bother checking for keys.
  71.  
  72.  >  > Also, building in more smarts, either with header keywords or
  73.  >  > configuration files to link Email addresses to public keys (for those
  74.  >  > who have a different Email address from what is on their key) might
  75.  >  > also be worthwhile.
  76.  > 
  77.  > Very nice idea!! Hey Richard, you're worth a gold bar. I'll rename my
  78.  > TODO file to RIL (Richard Idea List). :-)
  79.  
  80.   Aw, shucks. Another idea is to configure a resource file so that a
  81. user can default to "secure" "return-receipt" or whatever they choose.
  82. Also, keys/recipients can be tagged to always encrypt or never encrypt
  83. (why not just remove them from the keyring, you ask? Well, someone
  84. whooo doesn't want to receive encrypted messages, but has signed my
  85. key. I don't want an "unknown signator" entry :-)
  86.  
  87.                 Regards,
  88.  
  89.                     Richard....
  90. ======== END OF PGP BLOCK ========
  91.  
  92.